home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / tls / tls049.ltr < prev    next >
Text File  |  1994-09-02  |  8KB  |  219 lines
  1. subj: tls049 - POP mail server
  2.  
  3.  
  4. Useful hints, thanks to: Brian Atkinson:
  5.  
  6. This is compiled with C2 code. If you dont use C2 it seems to
  7. break with the message
  8.     Security command was invoked without ANY arguments
  9.  
  10. I altered popper.c and pop_pass.c so that where C2 was required, I had
  11.     #if defined(SCO) && defined(C2)
  12. which cured the problem.
  13.  
  14. Further to this, there are some funnies when sending a mail
  15. Attempting a reply (xtnd xmit) seems to give you the message
  16.      No valid author present
  17.  
  18. This is from sendmail, *not* popper. I'm not entirely sure what is
  19. causing this as it may be package related or the use of the sendmail
  20. flags within popper itself. However, many "pop" packages seem to use
  21. pop to pick up but then can use SMTP to send. I've simply configured
  22. our pop packages (B&W, QVTnet amongst others) to send with SMTP. I'll
  23. be honest and say I didnt spend any time worrying about it. I just
  24. switched to SMTP and forgot it.
  25.  
  26. However, it *does* work (after the C2 removal) and seems to be very reliable.
  27.  
  28. brian
  29.  
  30. -----------------------------
  31.  
  32.  
  33. From the README file:
  34.  
  35. Introduction
  36.  
  37. The Post Office Protocol server runs on a variety of Unix[1] computers
  38. to manage electronic mail for Macintosh and MS-DOS computers.  The
  39. server was developed at the University of California at Berkeley and
  40. conforms fully to the specifications in RFC 1081[2] and RFC 1082[3].
  41. The Berkeley server also has extensions to send electronic mail on
  42. behalf of a client.
  43.  
  44. Contents of the Distribution
  45.  
  46. The distribution contains the following:
  47.  
  48. +   All of the C source necessary to create the server program.
  49.  
  50. +   A visual representation of how the POP system works.
  51.  
  52. +   Reprints of RFC 1081 and RFC 1082.
  53.  
  54. +   A HyperCard stack POP client implementation using MacTCP.
  55.  
  56. +   A man page for the popper daemon.
  57.  
  58. +   This guide.
  59.  
  60.  
  61. Compatibility
  62.  
  63. The Berkeley POP server has been successfully tested on the following
  64. Unix operating systems:
  65.  
  66. +   Berkeley Systems Distribution 4.3
  67.  
  68. +   Sun Microsystems Operating System versions 3.5 and 4.0
  69.  
  70. +   Ultrix version 2.3
  71.  
  72. [ SCO UNIX version 4.2 ]
  73.  
  74. The following POP clients operate correctly with the Berkeley POP server:
  75.  
  76. +   The Berkeley HyperMail HyperCard stack for the Apple Macintosh 
  77.     (distributed with the server).
  78.  
  79. +   The Stanford University Macintosh Internet Protocol MacMH program.
  80.  
  81. +   The Stanford University Personal Computer Internet Protocol MH 
  82.     program.
  83.  
  84. +   The mh version 6.0 programs for Unix.
  85.  
  86.  
  87. Support
  88.  
  89. The Berkeley POP server is not officially supported and is without any
  90. warranty, explicit or implied.  However, we are interested in your
  91. experiences using the server.  Bugs, comments and suggestions should be
  92. sent electronically to netinfo@garnet.Berkeley.EDU.
  93.  
  94.  
  95. Operational Characteristics
  96.  
  97. The POP Transaction Cycle
  98.  
  99. The Berkeley POP server is a single program (called popper) that is
  100. launched by inetd when it gets a service request on the POP TCP port.
  101. (The official port number specified in RFC 1081 for POP version 3 is
  102. port 110.  However, some POP3 clients attempt to contact the server at
  103. port 109, the POP version 2 port.  Unless you are running both POP2 and
  104. POP3 servers, you can simply define both ports for use by the POP3
  105. server.  This is explained in the installation instructions later on.)
  106. The popper program initializes and verifies that the peer IP address is
  107. registered in the local domain, logging a warning message when a
  108. connection is made to a client whose IP address does not have a
  109. canonical name.  For systems using BSD 4.3 bind, it also checks to see
  110. if a cannonical name lookup for the client returns the same peer IP
  111. address, logging a warning message if it does not.  The the server
  112. enters the authorization state, during which the client must correctly
  113. identify itself by providing a valid Unix userid and password on the
  114. server's host machine.  No other exchanges are allowed during this
  115. state (other than a request to quit.)  If authentication fails, a
  116. warning message is logged and the session ends.  Once the user is
  117. identified, popper changes its user and group ids to match that of the
  118. user and enters the transaction state.  The server makes a temporary
  119. copy of the user's maildrop (ordinarily in /usr/spool/mail) which is
  120. used for all subsequent transactions.  These include the bulk of POP
  121. commands to retrieve mail, delete mail, undelete mail, and so forth.  A
  122. Berkeley extension also allows the user to submit a mail parcel to the
  123. server who mails it using the sendmail program (this extension is
  124. supported in the HyperMail client distributed with the server).  When
  125. the client quits, the server enters the final update state during which
  126. the network connection is terminated and the user's maildrop is updated
  127. with the (possibly) modified temporary maildrop.
  128.  
  129.  
  130. Logging
  131.  
  132. The POP server uses syslog to keep a record of its activities.  On
  133. systems with BSD 4.3 syslogging, the server logs (by default) to the
  134. "local0" facility at priority "notice" for all messages except
  135. debugging which is logged at priority "debug".  The default log file is
  136. /usr/spool/mqueue/POPlog.  These can be changed, if desired.  On
  137. systems with 4.2 syslogging all messages are logged to the local log
  138. file, usually /usr/spool/mqueue/syslog.
  139.  
  140. Problems
  141.  
  142. If the filesystem which holds the /usr/spool/mail fills up users will 
  143. experience difficulties.  The filesystem must have enough space to hold
  144. (approximately) two copies of the largest mail box.  Popper (v1.81 and
  145. above) is designed to be robust in the face of this problem, but you may
  146. end up with a situation where some of the user's mail is in
  147.  
  148.     /usr/spool/mail/.userid.pop
  149.  
  150. and some of the mail is in
  151.  
  152.     /usr/spool/mail/userid
  153.  
  154. If this happens the System Administrator should clear enough disk space
  155. so that the filesystem has at least as much free disk as both mailboxes
  156. hold and probably a little more.  Then the user should initiate a POP
  157. session, and do nothing but quit.  If the POP session ends without an
  158. error the user can then use POP or another mail program to clean up his/her
  159. mailbox.
  160.  
  161. Alternatively, the System Administrator can combine the two files (but
  162. popper will do this for you if there is enough disk space).
  163.  
  164.  
  165. Debugging
  166.  
  167. The popper program will log debugging information when the -d parameter
  168. is specified after its invocation in the inetd.conf file.  Care should
  169. be exercised in using this option since it generates considerable
  170. output in the syslog file.  Alternatively, the "-t <file-name>" option
  171. will place debugging information into file "<file-name>" using fprintf
  172. instead of syslog.  (To enable debugging, you must edit the Makefile
  173. to add -DDEBUG to the compiler options.)
  174.  
  175. For SunOS version 3.5, the popper program is launched by inetd from
  176. /etc/servers.  This file does not allow you to specify command line
  177. arguments.  Therefore, if you want to enable debugging, you can specify
  178. a shell script in /etc/servers to be launched instead of popper and in
  179. this script call popper with the desired arguments.
  180.  
  181. Limitations
  182.  
  183. +   The POP server copies the user's entire maildrop to /tmp and
  184.     then operates on that copy.  If the maildrop is particularly
  185.     large, or inadequate space is available in /tmp, then the
  186.     server will refuse to continue and terminate the connection.
  187.  
  188. +   Simultaneous modification of a single maildrop can result in 
  189.     confusing results.  For example, manipulating messages in a
  190.     maildrop using the Unix /usr/ucb/mail command while a copy of
  191.     it is being processed by the POP server can cause the changes
  192.     made by one program to be lost when the other terminates.  This
  193.     problem is being worked on and will be fixed in a later
  194.     release.
  195.  
  196.  
  197. Credits
  198.  
  199. The POP server was written by Edward Moy and Austin Shelton with
  200. contributions from Robert Campbell (U.C. Berkeley) and Viktor Dukhovni
  201. (Princeton University).  Edward Moy wrote the HyperMail stack and drew
  202. the POP operation diagram.  This installation guide was written by
  203. Austin Shelton.
  204.  
  205.  
  206. Footnotes
  207.  
  208. [1] Copyright (c) 1990 Regents of the University of California.
  209.     All rights reserved.  The Berkeley software License Agreement
  210.     specifies the terms and conditions for redistribution.  Unix is
  211.     a registered trademark of AT&T corporation.  HyperCard and
  212.     Macintosh are registered trademarks of Apple Corporation.
  213.  
  214. [2] M. Rose, Post Office Protocol - Version 3.  RFC  1081, NIC, 
  215.     November 1988.
  216.  
  217. [3] M. Rose, Post Office Protocol - Version 3 Extended Service 
  218.     Offerings.  RFC 1082, NIC, November 1988.
  219.